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METHOD AND SYSTEM FOR GENERATING STATISTICALLY-BASED 
MEDICAL PROVIDER UTILIZATION PROFILES 

Microfiche Appendix 

This specification includes a Microfiche Appendix which includes 1 
page of microfiche with a total of 37 frames. The microfiche appendix includes 
computer source code of one preferred embodiment of the invention. In other 
embodiments of the invention, the inventive concept may be implemented in other 
computer code, in computer hardware, in other circuitry, in a combination of these, or 
otherwise. The Microfiche Appendix is hereby incorporated by reference in its entirety 
and is considered to be a part of the disclosure of this specification. 

1. Background of the Invention 

A. Field of the Invention ; 

The invention relates to methods and systems for analyzing medical ' 
claims histories and billing patterns to statistically establish treatment utilization ^ 
patterns for various medical services. Data is validated using statistical and clinically 
derived methods. Based on historical treatment patterns and a fee schedule, an accurate 
model of the cost of a specific medical episode can be created. Various treatment 
patterns for a particular diagnosis can be compared by treatment cost and patient 
outcome to determine the most effective treatment approach. It is also possible to 
identify those medical providers who provide treatment that does not fall within the 
statistically established treatment patterns or profiles. 

B. The Background Art 

It is desirable to compare claims for reimbursement for medical services 
against a treatment pattern developed from a large body of accurate medical provider 
billing history information. Although in the prior art some attempt was made to 
compare claims for reimbursement for medical services to a normative index, the prior 
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( 

art did not construct the normative index based on actual clinical data. Rather, the prior 
art based the normative index on a subjective conception (such as the medical consensus 
of a specialty group) of what the proper or typical course of treatment should be for a 
given diagnosis. Such prior art normative indices tended to vary from the reality of 
medical practice. In the prior art, automated medical claims processing systems, 
systems for detecting submission of a fraudulent medical claims, and systems for 
providing a medical basehne for the evaluation of ambulatory medical services were 
known. Documents which may be relevant to the background of the invention, 
including documents pertaining to medical reimbursement systems, mechanisms for 
detecting fraudulent medical claims, and related analytical and processing methods, 
were known. Examples include: U.S. Pat. No. 4,858,121, entitled "Medical Payment 
System" and issued in the name Barber et al. on Aug. 15, 1989; U.S. Pat. No. 5,253,164, 
entitled "System and Method for Detecting Fraudulent Medical Claims Via 
Examination of Service Codes" and issued in the name of Holloway et al. on Oct. 12, 
1993; U.S. Pat. No. 4,803,641, entitled "Basic Expert System Tool" and issued in the 
name of Hardy et al. on Feb. 7, 1989; U.S. Pat. No. 5,658,370, entitled "Knowledge 
Engineering Tool" and issued in the name of Erman et al. on Apr. 14, 1987; U.S. Pat. 
No. 4,667,292, entitled "Medical Reimbursement Computer System" and issued in the 
name of Mohlenbrock et al. on May 19, 1987; U.S. Pat. No. 4,858,121, entitled 
"Medical Payment System" and issued in the name of Barber et al. on Aug. 15, 1989; 
and U.S. Pat. No. 4,987,538, entitled "Automated Processing of Provider Billings" and 
issued in the name of Johnson et al. on Jan. 22, 1991, each of which is hereby 
incorporated by reference in its entirety for the material disclosed therein. 

Additional examples of documents that may be relevant to the 
background of the invention are: Leape, "Practice Guidelines and Standards: An 
Overview," QRB (Feb. 1990); Jollis et al., "Discordance of Databases Designed for 
Claims Payment versus Clinical Information Systems," Annals of Internal Medicine 
(Oct. 15, 1993); Freed et al., "Tracking Quality Assurance Activity," American College 
of Utilization Review Physicians (November, 1988); Roberts et al., "Quality and Cost- 
Efficiency," Amenc^i_Conegeof^^ 1988), 

2 

Marked up version of Second Substitute Specification showing changes to Specification of record. 
TO BE USED FOR ILLUSTRATION PURPOSES ONLY 



Rodriguez, "Literature Review," Quality Assurance and Utilization Review - Official 
Journal of the American College of Medical Quality (Fall 1991); Elden, "The Direction 
of the Healthcare Marketplace," Journal of the American College of Utilization Review 
Physicians (August 1989); Rodriguez, "Literature Review," Quality Assurance and 
Utilization Review - Official Joumal of the American College of Medical Quality (Fall 
1991); Roos et al., "Using Administrative Data to Predict Important Health Outcomes," 
Medical Care (March 1988); Bums et al, "The Use of Continuous Quality Improvement 
Methods in the Development and Dissemination of Medical Practice Guidelines, QRB 
(December, 1992); Weingarten, "The Case for Intensive Dissemination: Adoption of 
Practice Guidelines in the Coronary Care Unit," QRB (December, 1992); Flagle et al., 
"AHCPR-NLM Joint Initiative for Health Services Research Information: 1992 Update 
on OHSRI," QRB (December, 1992); Holzer, "The Advent of Clinical Standards for 
Professional Liability," QRB (February, 1990); Gottleib et al., "Clinical Practice 
Guidelines at an HMO: Development and Implementation in a Quality Improvement 
Model," QRB (February, 1990); Borbas et al., "The Minnesota Clinical Comparison and 
Assessment Project," QRB (February, 1990); Weiner et al., "Applying Insurance Claims 
Data to Assess QuaUty of Care: A Compilation of Potential Indicators," QRB 
(December, 1990); Wakefield et al., "Overcoming the Barriers to Implementation of 
TQM/CQI in Hospitals: Myths and Realities," QRB (March, 1993); Donabedian, "The 
Role of Outcomes in Quality Assessment and Assurance," QRB (November, 1992); 
Dolan et al., "Using the Analytic Hierarchy Process (AHP) to Develop and Disseminate 
Guidelines," QRB (December, 1992); Hadom et al., "An Annotated Algorithm 
Approach to Clinical Guideline Development," JAMA (Jun. 24, 1992); Falconer et al., 
"The Critical Path Method in Stroke Rehabilitation: Lessons fi-om an Experiment in 
Cost Containment and Outcome Improvement," QRB (January, 1993); Reinertsen, 
"Outcomes Management and Continuous Quality Improvement: The Compass and the 
Rudder," QRB (January, 1993); Mennemeyer, "Downstream Outcomes: Using 
Insurance Claims Data to Screen for Errors in Clinical Laboratory Testing," QRB (June, 
1991); lezzoni, "Using Severity Information for Quality Assessment: A Review of 
Three Cases by Five Severity Measures," QRB (December 1989); Kahn, "Measuring the 
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Clinical Appropriateness of the Use of a Procedure," Medical Care (April, 1988); Wall, 
"Practice Guidelines: Promise or Panacea?," The Journal of Family Practice (1993); 
Lawless, "A Managed Care Approach to Outpatient Review," Quality Assurance and 
Utilization Review - Official Journal of the American College of Utilization Review 
Physicians (May, 1990); Dragalin et al., "Institutes for Quality: Prudential's Approach 
to Outcomes Management for Specialty Procedures," QRB (March, 1990); Chinsky, 
"Pattems of Treatment Ambulatory Health Care Management, Physician Profiling - The 
Impact of Physician, Patient, and Market Characteristics On Appropriateness of 
Physician Practice in the Ambulatory Setting," (Doctoral Dissertation, The University 
of Michigan, 1991), pubhshed by Concurrent Review Concurrent Review Technology, 
Inc., Shingle Springs, CaUfomia; "Pattems of Treatment Ambulatory Health Care 
Management, Implementation Guide," published by Concurrent Review Concurrent 
Review Technology, Inc., Shingle Springs, Cahfomia; "Pattems of Treatment 
Ambulatory Health Care Management, Pattems Processing Model," published by 
Concurrent Review Concurrent Review Technology, Inc., Shingle Springs, California; 
Report on Medical Guidelines & Outcome Research , 4 (Feb. 11, 1993); "Practice 
Guidelines - The Experience of Medical Specialty Societies," United States General 
Accounting Office Report to Congressional Requestors (GAO/PEMD-91-1 1 Practice 
Guideline) (Feb. 21, 1991); "Medicare Intermediary Manual Part 3 - Claims Process," 
Department of Health and Human Services, Health Care Financing Administration, 
Transmittal No. 1595 (April 1993); CCH Pulse The Health Care Reform Newsletter 
(Apr. 19, 1993); Winslow, "Report Card on Quality and Efficiency of HMOs May 
Provide a Model for Others," The Wall Street Journal ; Jencks et al., "Strategies for 
Reforming Medicare's Physician Payments," The New England Joumal of Medicine 
(Jun. 6, 1985); Solon et al., "Delineating Episodes of Medical Care," AJ.P.H. (March, 
1967); Health Care (September, 1986) (the enfire issue of Volume 24, Number 9, 
Supplement); Miller et al., "Physician Charges in the Hospital," Medical Care (July, 
1992); Gamick, "Services and Charges by PPO Physicians for PPO and Indemnity 
Patients," Medical Care (October, 1990); Hurwicz et al., "Care Seeking for 
Musculoskeletal and Respiratory Episodes in a Medicare Population," Medical Care 
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(November, 1991), Gold, "The Content of Adult Primary Care Episodes," Public Health 
Reports (January-February, 1982); Welch et al., "Geographic Variations in Expenditures 
for Physicians* Services in the United States," The New England Journal of Medicine 
(Mar. 4, 1993); Schneeweiss et al., "Diagnosis Clusters: A New Tool for Analyzing the 
Content of Ambulatory Medical Care," Medical Care (January, 1983); Showstack, 
"Episode-of-Care Physician Payment: A Study of Coronary Arter Bypass Graft 
Surgery," Inquiry (Winter, 1987); Schappert, "National Ambulatory Medical Survey: 
1989 Summary," Vital and Health Statistics, U.S. Department of Health and Human 
Services, Public Health Service, Centers for Disease Control, National Center for Health 
Statistics (April, 1992) (DHHS Publication No. [PHS] 92-1771); Graves, "Detailed 
Diagnoses and Procedures, National Hospital Discharge Survey, 1990," Vital and 
Health Statistics, U.S. Department of Health and Human Services, Public Health 
Service, Centers for Disease Control, National Center for Health Statistics (June, 1992) 
(DHHS Publication No. [PHS] 92-1774); "National Hospital Discharge Survey: Annual 
Summary, 1990," Vital and Health Statistics, U.S. Department of Health and Human 
Services, Public Health Service, Centers for Disease Control, National Center for Health 
Statistics (June, 1992) (DHHS Publication No. [PHS] 92-1773); "Prevalence of Selected 
Chronic Conditions: United States, 1986-88," Vital and Health Statistics, U.S. 
Department of Health and Human Services, Public Health Service, Centers for Disease 
Control, National Center for Health Statistics (February, 1993) (Series 10, No. 182); 
"Current Estimates From the National Health Interview Survey, 1991," Vital and Health 
Statistics, U.S. Department of Health and Human Services, PubUc Health Service, 
Centers for Disease Control, National Center for Health Statistics (February, 1993) 
(DHHS Publication No. [PHS] 93-1512); lezzoni et al., "A Description and Clinical 
Assessment of the Computerized Severity Index," QRB (February, 1992); Health Care 
Financing Review , p. 30 (Winter, 1991); Statistical Abstract of the United States 
(1992); and Health and Prevention Profile - United States (1991) (published by U.S. 
Department of Health and Human Services, PubUc Health Service, Centers for Disease 
Control, National Center for Health Studies), each of which is hereby incorporated by 
reference in its entirety for the material disclosed therein. 
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Additional background materials to which the reader is directed for both 
background and to refer to while studying this specification include: Physicians' Current 
Procedural Terminology CPT '94 , published by American Medical Association, Code it 
Right Techniques for Accurate Medical Coding , published by Medicode Inc., HCPCS 
1994 Medicare's National Level II Codes , published by Medicode Inc., Med-Index ICD 
9 CM Fourth Edition 1993 , published by Med-Index, each of which is hereby 
incorporated by reference in its entirety for the material disclosed therein. 

II. Summary of the Invention 

It is an object to provide a mechanism for assessing medical services 
utihzation patterns. The invention achieves this object by allowing comparison 
processing to compare an individual treatment or a treatment group against a statistical 
norm or against a trend. 

It is an object of the invention to provide a mechanism for converting 
raw medical providers' billing data into a database. The invention achieves this object 
by read, analyze and merge ("RAM") processing coupled with claims edit processing to 
achieve a reliable, relevant data set. 

It is an object of the invention to provide a mechanism for accurately 
determining an episode of care. The invention achieves this object by providing a 
sequence of steps which, when performed, yield an episode of care while filtering out 
irrelevant and inapplicable data. 

It is an object of the invention to provide a method for performing a 
look-up of information, that is, providing a mechanism for gaining access to different 
parts of the informational tables maintained in the database. This object is achieved by 
reviewing the referenced tables for specific codes representing specific diagnoses. The 
codes are verified for accuracy. Then tables are accessed to display selected profiles. 
Users are then given the opportunity to select profiles for comparison. 

It is an object of the invention to provide a method for comparing 
profiles. This object is achieved by comparing index codes against historical reference 
information. Discovered information is checked against defined statistical criteria. The 
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process is repeated for each index code and its profiles developed in the history process 
as many times as necessary to complete the information gathering. 

It is an object of the invention to create, maintain and present to the user 
a variety of report products. These reports are provided either on-Une or in a hard copy 
format. The process of creating, maintaining and presenting these reports is designed to 
present relevant information in a complete and useful manner. 

It is an object of the invention to provide a mechanism for creating a 
practice parameter database. This object is achieved in the invention by repetitive 
episode of care processing and entry of processed episode of care data into a data table 
until the populated data table becomes the practice parameter database. 

III. Brief Description of the Drawings 

FIG. 1 depicts steps performed in the method of the invention to 
estabUsh a practice parameter or utihzation profile for a particular diagnosis. 
FIG. 2 depicts an episode of care for a single disease. 
FIG. 3 depicts an episode of care for concurrent diseases, 
FIG. 4 depicts potential outcomes for an episode of care. 
FIG. 5 depicts phases of an episode of care. 

FIGs. 6-8 depicts processing of data before episode of care processing 

begins. 

FIG. 9 depicts episode of care processing. 

FIG. 10 depicts principle elements of the invention and their relationship 

to each other. 

FIG. 1 1 depicts the process of the preferred embodiment of the Read, 
Analyze, Merge element of the invention. 

FIG. 12 depicts the process of the preferred embodiment of the Episode 
of Care element of the invention. 

FIG. 13 depicts the process of the preferred embodiment of the Look-up 
element of the invention. 



7 



Marked up version of Second Substitute Specification showing changes to Specification of record. 
TO BE USED FOR ILLUSTRATION PURPOSES ONLY 



FIG. 14 depicts the process of the preferred embodiment of the Subset 
Parameter Look-up component of the Look-up element of the invention. 

FIG. 15 depicts the process of the preferred embodiment of the Profile 
Comparison element of the invention. 

IV, Detailed Description of the Preferred Embodiment 

The invention includes both a system and a method for analyzing 
healthcare providers' billing pattems, enabling an assessment of medical services 
utilization patterns. When the invention is employed, it can readily be seen whether a 
provider or multiple providers are overutilizing or underutilizing services when 
compared to a particular historical statistical profile. The statistical profiles of the 
invention are a statically-derived norms based on clinically-validated data which has 
been edited to eliminate erroneous or misleading information. The profiles may be 
derived firom geographic provider billing data, national provider billing data, the 
provider billing data of a particular payor entity (such as an insurance company) or 
various other real data groupings or sets. Multiple informational tables are used in the 
database of the preferred embodiment of the invention. These include a Procedure 
Description Table, ICD-9 Description Table, Index Table, Index Global Table, Index 
Detail Table, Window Table, Procedure Parameter Table, Category Table, Qualifying 
Master Table, Specialty Table, Zip/Region Table, Specialty Statistic Table, Age/Gender 
Statistic Table, Region Statistic Table, Quahfying Index Table, Qualifying Group 
Table, Category Parameter Table, and Duration Parameter Table. ICD 9 codes or ICD 
(Intemational Classification of Diseases, generically referred to as a disease 
classification) codes as they are generally referred to herein are used in the preferred 
embodiment. In other embodiments of the invention other codes could be used, such as: 
predecessors or successors to ICD codes or substitutes therefor, such as DSM 3 codes, 
SNOWMED codes, or any other diagnostic coding schemes. These tables are described 
in detail as follows. It should be noted, however, that these tables described are used by 
the inventors in one implementation of the invention, and that the inventive concept 
described herein may be implemented in a variety of ways. 
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PROCEDURE DESCRIPTION TABLE 

This table identifies and validates five years of both CPT (Current Procedural 
Terminology, generically referred to as an identifying code for reporting a medical 
service) and HCPCS level II procedure codes. The lifetime occurrence maximum and 
follow-up days associated with a procedure code are also located in this table. 



Code (Key) 


Alpha/Numeric 


5 


Standard CPT or HCPCS (5 Years including 
Modifiers) 


oUD-v^oae 


Character 


L 


* — Starred Procedures 
N = New Codes Current Year 
Dl = Deleted Code Current Year 
D2 = Deleted Code Previous Year 
D3 = Deleted Code Third Year 
D4 = Deleted Code Fourth Year 
C Changed Description 


Life Time 
Occurrence 


Numeric 


2 


Number = Count of occurrence in a lifetime 
Blank = Not apphcable 


Follow Up Days 


Numeric 


3 


Number of Follow up Days to procedure. 


Description 


Character 


48 


Standard abbreviated description 



Total 60 



USE: 

• This table can validate CPT and HCPCS codes. 

• Five years of codes will be kept. 

• Give a brief description of the code. 

• Gives the maximum number of occurrences that this code can be done in a 
lifetime, if applicable. (Programming not addressed, to date) 

• Give the number of follow up days to a procedure. (Programming not addressed, 
to date) 

• Modifiers are stored in this table with a "099" prefix (i.e., the 80 modifier is 
"09980") with a description of the modifier. 

• This table interrelates with: 
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- Parameter Tables 

- Category Table 

- Qualifying Tables 

- Specialty Table 

- CPT Statistic Table 

ICD-9 DESCRIPTION TABLE 

This table identifies and validates five years of diagnosis codes. It also 



contains a risk adjustment factor for each diagnosis. 



ICD-9 Code (Key) 


Alpha/Numeric 


5 


Left justified, assumed decimal after 3rd 
position 


Sub-Code 


Character 


2 


N = New Code 
D = Deleted Code 
C = Changed Code 


Indicator 


Character 


1 


* or blank 

* = code requires 4th and/or 5th digits to be 
specific 


Risk 


Alpha/Numeric 


2 


Overall Classification of Disease 


Description 


Character 


48 


Standard abbreviated description 



Total 58 
USE: 

• This table can validate ICD codes. 

• Five years of codes w^ill be kept. 

• Give a brief description of the code. 



• Show if the code is incomplete and in need of a fourth or fifth digit. An ICD code 
which should have a 4th and/or 5th digit is listed with an 

• This file interrelates with: 

- Index Table 

- Index Detail Table 

- Index Global Table 

- Qualifying Master Table 
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- Family Table 

- All Parameter Tables 



INDEX DETAIL TABLE 

This table identifies ICD-9 codes relevant to each specific index code 
and is used to drive the search for each episode of care. ICD-9 codes have been given 
an indicator which determines whether or not the associated CPT code should be 
included in the episode of care. Also, an indicator may cause exclusion of any specific 
patient record from an episode of care analysis. 



Index Code 


Alpha/Numeric or 
character 


5 


Left justified assumed decimal after 3rd 
position. 


Indicator 


Character 


2 


I = Index code 

R = Related 

S = signs/symptoms 

RO - Rule out 

C = complications (exclude) 

M = miscoded 

V = Vcodes 

MI = Miscoded Index 


Beg-ICD 


Alpha/Numeric 


5 


ICD-9 Beginning Range Code 


End-ICD 


Alpha/Numeric 


5 


ICD-9 Ending Range Code 


Update 


Character 


1 


A, C, or Blank 



Total 17 
USE: 



• This table drives the search for the Episode of Care (EOC) and is keyed off the 
Index Code field. 

• Other codes to be included in the parameter search are specified in the indicator 
field. 

• ICD codes with an indicator of "C" when found in a patient history will disqualify 
the entire patient from the EOC process. 

• "Some Index Codes are listed in part with and "??" to exhibit that it does not 
matter what the trailing 4th and/or 5th digit is, the record is to be accessed for the 
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parameter. For example, the Index code may be 701??, meaning that if the first 
three digits of the ICD code start with 701 then use the code regardless of what the 
4th and/or 5th digit may be." 

• ICD codes maintained in this table are listed as complete as verified by the ICD 
description table, with the exception of ICD codes beginning with an indicator of 
"M". Programming logic should consider this when using "M" codes in the search 
process. 

• This table is used for drafting and populating a temporary file built from this table 
and the Index Global Table based on indicators and keys extrapolated from the 
Index table. 

PROGRAM LOGIC TO ASSIGN EPISODE OF CARE 

• Any patient history with an ICD fi-om the temp file for the chosen Index code is 
tagged for possible assignment of Episode of Care. 

• Perform a search on patient history for any ICD code from temp file with an 
indicator of "C". If found, exclude entire patient history fi-om EOC search. 

• The quahfying tables are accessed to verify if specific qualifying factors apply to 
determine if patient history meets criteria for determination of valid episode of 
care. (See Qualifying Tables for further explanation) 

• The qualifying table is then accessed for further delineation of qualifying 
circumstances by EOC. 

• A timeline is tracked, by patient, for all potential Episodes of care that may occur 
for a given patient history. 

• The data is arrayed based on profile classes which are eight subsets of Procedure 
categories. An aggregate of all procedures can also be reported. (See Category 
Table for further explanation) 

• This table interrelates with: 

- ICD Description Table 

- Index Table 

- Index Global Table 

- Parameter Table 
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CPT Statistic Table 
- Age/Sex Table 

INDEX TABLE 



This table provides a preliminary step for assigning and accessing 
different tables during the Episode of Care process. This table houses the assignment of 
staging and whether or not the Index Global table should be accessed. 



Index Code 


Alpha/Numeric 


5 


Left justified assumed decimal after 3rd 
position. 


Staging 


Character 


2 


P - preventive 

A - acute 

C = chronic 

L = life threatening 

M = manifestations 


Global Key 


Alpha 


2 


C ~ complications 

Ml = miscoded medical vcodes 

M2 = miscoded surgical vcodes 

1= medical vcodes 

2 = surgical vcodes 


Indicator 


Character 


2 


C = complications 
V = vcodes 


Update 


Character 


1 


A, C, or Blank 



Total 12 



USE: 

• Once an Index code has been selected, this table is searched for whether or not the 
global index table needs to be accessed. 

• This table assigns the staging for the index code which points to the window table. 

• This table interrelates with: 

- ICD Description Table 

- Index Detail Table 
Index Global Table 

- Window Table 
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INDEX GLOBAL TABLE 



This table gives a listing of ICD-9 codes common to most Index codes 
for either inclusion in an EOC such as preventive or aftercare, or exclusion of a patient 
history such as medical complications. 



GLOBAL KEY 


Alpha/Numeric 


2 


C = complications 

Ml = miscoded medical vcodes 

M2 = miscoded surgical vcodes 

1 = medical vcodes 

2 = surgical vcodes 


ICD Beginning 


Alpha/Numeric 


5 


ICD-9 Beginning range code 


ICD Ending 


Alpha/Numeric 


5 


ICD-9 Ending range code 


Update 


Character 


1 


A, C, or Blank 



Total 13 
USE: 



• This table is used to identify a generic V Code or complication ICD code to be 
used in an EOC search for any Index code. 

• It is triggered by the Index table. 

• The surgical Vcodes include all Ml, M2, 1 and 2*s. 

• Medical Vcodes include Ml and 1. 

• A comphcation ICD code will negate the use of a patient history from the EOC 
search. 

• A temporary file for the index code is created based on ICDs extrapolated from 
this table as well as the Index detail table 

• This table interrelates with: 

- ICD Description Table 
Index Table 

- Index Detail Table 
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WINDOW TABLE 

This table contains the time period preceding and following an episode 
of care that must be present without any services provided to the patient relating to the 
index code or associated codes. These windows are used to define the beginning and 
end points of an episode of care. This table is driven from the staging field in the index 
table. 



TnHpv r^r»Hp 


Numeric 


5 


Left justified assumed decimal after 3rd 
position 


Staging Indicator 


Character 


2 


P = Preventive 

C = Chronic, A = Acute 

L = Life threatening, M = Manifestation 


Beginning Window 


Numeric 


3 


Time Period for no occurrence of ICD for 
Index Code 


Ending Window 


Numeric 


3 


Time Period for no occurrence of ICD for 
Index Code 


Update 


Character 


1 


A, C, or Blank 



Total 9 
USE: 

• This table is keyed off of the staging indicator and it tells the program how long of 



a "Clear Window" is needed on both ends of this EOC for it to be valid. 
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PROCEDURE PARAMETER TABLE 

This table contains the specific CPT codes identified for each index code 



listed chronologically with associated percentiles, mode, and average. 



Index Code 


Alpha/Numeric 


5 


Left justified assumed decimal after 3rd 
position 


Profile 


Alpha/Numeric 


2 


Mnemonic 


Procedure 


Alpha/Numeric 


5 


CPT, HCPCS 


timeframe 


Alpha/Numeric 


3 


Mnemonic for timeframe or total 


50th percentile 


Numeric 


4 


Beginning percentile range 


50th percentile 


Numeric 


4 


ending percentile range 


75th percentile 


Numeric 


4 


begirming percentile range 


75th percentile 


Numeric 


4 


ending percentile range 


95th percentile 


Numeric 


4 


beginning percentile range 


95th percentile 


Numeric 


4 


ending percentile range 


Mode 


Numeric 


3 


Numeric Count 


Count 


Numeric 


7 


Number of EOCs for timeframe 


Sum 


Numeric 


7 


Number of services for timeframe 


Weighting 


Numeric 


6 


Numeric count, assumed decimal (4.2) 


Update 


Character 


1 


A, C, or Blank 



Total 63 
USE: 

• This table shows which CPTs are historically billed and statistically how often for 



a Specific Index Code. 
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CATEGORY PARAMETER TABLE 

This table contains a listing of the procedural categories identified for 



each index code listed chronologically with associated percentiles, mode, and average. 



Index Code 


Alpha/Numeric 


5 


Left justified assumed decimal after 3rd 
position. 


Profile 


Alpha/Numeric 


2 


Mnemonic 


Category 


Alpha/Numeric 


4 


category 


timeframe 


Alpha/Numeric 


3 


Mnemonic of timeframe or total 


50th percentile 


Numeric 


4 


beginning percentile range 


50th percentile 


Numeric 


4 


ending percentile range 


75th percentile 


Numeric 


4 


beginning percentile range 


75th percentile 


Numeric 


4 


ending percentile range 


95th percentile 


Numeric 


4 


beginning percentile range 


95th percentile 


Numeric 


4 


and ending percentile range 


Mode 


Numeric 


3 


Numeric Count, assumed decimal (4.2) 


Count 


Numeric 


7 


Number of EOCs for the timeframe 


Sum 


Numeric 


7 


Number of services for the timeframe 


Update 


Character 


1 


A, C, or Blank 



Total 56 
USE: 



• This table shows which Procedural Categories are historically billed and 
statistically how often for a Specific Index Code. 
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DURATION PARAMETER TABLE 

This table contains the EOC duration distribution for a given Index code. 



Index Code 


Alpha/Numeric 


5 


Left justified assumed decimal after 3rd 
position. 


Profile 


Alpha/Numeric 


2 


Mnemonic 


50th percentile 


Numeric 


4 


beginning range 


50th percentile 


Numeric 


4 


ending range 


75 th percentile 


Numeric 


4 


beginning range 


75th percentile 


Numeric 


4 


ending range 


95th percentile 


Numeric 


4 


begiiming range 


95th percentile 


Numeric 


4 


ending range 


Mode 


Numeric 


3 


beginning and ending range 


Update 


Character 


2 


A = Add 
C = Change 



Total 36 
USE: 



• This table gives access to Statistical information about EOC durations of care for a 
given index code. 

• It interrelates with: 

- Index Detail table 

- Parameter table 



CATEGORY TABLE 

This Table provides a grouping of CPT codes into categories of similar 

services. 



Category 


Alpha/Numeric 


4 


Mnemonics 


Beg-CPT 


Alpha/Numeric 


5 


Beginning CPT Range 


End-CPT 


Alpha/Numeric 


5 


Ending CPT Range 


Update 


Character 


1 


A, C, or Blank 



Total 15 
USE: 
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Procedure codes have been categorized according to most likely type of service 

they may represent. It could be characterized as a sorting mechanism for 

procedure codes. 

The mnemonic used for this category is as follows: 

E, =Maior E and M =Minor E and M 

Li =Maior Laboratory =Minor Laboratory 

Rm =Maior Diagnostic Radiology Rn ? =Minor Diagnostic Radiology 

Rti =Maior Therapeutic Radiology R nn ^^Minor Therapeutic Radiology 

O, =Maior Oncology Radiology ==Minor Oncology Radiology 

Mm =Maior Diagnostic Medicine M n? =Minor Diagnostic Medicine 

Mt. =Maior Therapeutic Medicine M t^ =Minor Diagnostic Medicine 

Sm =Maior Diagnostic Surgery S r ^ =Minor Diagnostic Surgery 

Sji =Maior Therapeutic Surgery S t9 =Minor Therapeutic Surgery 

A, =Maior Anesthesia -Minor Anesthesia 

P, =Pathology J=Adiunct 

Categories are also used for arraying Episodes of Care into profile classes or can 
be reported as an aggregate. The subsets of the aggregate are: 



0 


Common Profile 


1 


Surgery/Radiation/Medicine Profile 


2 


Medicine/Radiation Profile 


3 


Surgery/Radiation Profile 


4 


Surgery/Medicine Profile 


5 


Radiation Profile 


6 


Medicine Profile 


7 


Surgery Profile 



This table interrelates with: 



Parameter Table 
Qualifying Tables 
Procedure Table 
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QUALIFYING MASTER TABLE 

This table provides a preliminary step for determining qualifying 
circumstances that may eliminate a patient history for determination of an Episode of 
Care. It also provides the initial sort of an episode of care for a specific profile class. 



Index Code 


Alpha/Numeric 


5 


Left justified, assumed decimal after 3rd 
position 


Scope 


Alpha 


1 


P = Patient 

E = Episode of Care 

B = Both 


Profile 


Alpha/Numeric 


2 


Mnemonic or Blank 


Group 


Alpha/Numeric 


5 


Correlates to group ID in Qualifying Group 
Table 


Update 


Character 


1 


A, C, or Blank 



Total 14 
USE: 



• Preliminary step in EOC qualifying process. 

• This table interrelates with: 

- Index Detail Table 

- Qualifying Group Table 

• The Scope field of the Qualifying Master Table outlines which set of qualifying 
circumstances are to be apphed. The values of the Scope field include P=patient 
level, E^Episode of Care level, or B= both. 

• The Profile field is numbered based on the 8 different profiles (also outlined under 
the category table. If blank, a profile is not relevant. They are as follows: 

0. Common Profile 

1 . Surgery/Medicine/Radiation Profile 

2. Medicine/Radiation Profile 

3. Surgery/Radiation Profile 

4. Surgery/Medicine Profile 
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5. Radiation Profile 

6. Medicine Profile 

7. Surgery Profile 

• The Group field assigns a 5 byte mnemonic that establishes a set of qualifying 
rule sets for a given index code. This field keys directly to the Qualifying Group 
Table, The majority of the groups relate to profile classes. 

QUALIFYING GROUP TABLE 

This table groups certain qualifying circumstances to aid in an efficient 



search for data meeting the criteria. 



Group 


Alpha/Numeric 


5 


Left justified assumed decimal after 3rd 
position 


Rule Type 


Alpha/Numeric 


2 


II = Index Code specific rule 

IS = specific ICD code rule 

IC ^ multiple ICD to category rule 

CC = Multiple code rule 

CS = code specific rule 

IG = ICD to gender rule 

lA = ICD to age rule 


[Rule4deB:tifieF] 
Logical 


Alpha/Numeric 


1 


T = True F = False (toggle) 


Rule Identifier 


Alpha/Numeric 


1 


M = Male F = Female if IG rule type 


Number required 


numeric 


2 


number value 


Update 


Character 


1 


A, C, or Blank 



Total 15 
USE: 



• This table groups all rules qualifying EOCs. 

• This table interrelates with: 

- Qualifying Index Table 

- Qualifying Code Table 

- Qualifying Master Table 
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• A rule type (or rule types) is assigned by group delineating if the rule applies to a 
single or multiple ICD, single or multiple CPT or category or any combination 
thereof. 

• The Rule Type is a mnemonic which assigns a common type of logic that is to be 
implemented in the search for the qualifying circumstances. It is possible that the 
same rule type could be associated with many different rule identifiers. The rule 
type will also point to either the QuaUfying Index Table or the Qualifying Code 
Table. 

The following is a listing of the rule types. (One skilled in the art would 
understand that additional rule types and associated programming logic may be 
implemented): 

Rule Types associated with Qualifying Index Table: 
II This related directly to the Index code only. 

IC This rule is for any indicated ICD code associated with the Index code as it 
relates to a category or procedure. 

IS This rule is for a specific indicated ICD code associated with the Index code as 
it relates to a category or procedure. 

IG This rule is for any indicated ICD code associated with the Index code as it 
relates to age. 

Rule Types associated with Qualifying Code Table: 

CC This rule is for a specific procedure or category as it relates to another specific 
procedure or category for any ICD code associated with the Index code. 
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CS This is for a specific procedure or category as it relates to a specific ICD code 
associated with the Index code. 

• The rule identifier is an assigned mnemonic based on what the rule is to achieve. 

• The Logical indicates if the rule is positive or negative (inclusionary or 
exclusionary) 

• The Number Required is a count of the number of occurrences required for the 
rule to be valid. 

QUALIFYING INDEX TABLE 

Table houses qualifying circumstances based on presence or non- 
existence of Specific procedures and/or ICD codes that would qualify or disqualify a 
patient history in the determination of an Episode of Care. 



Rule Type 


Alpha/Numeric 


2 


II = Index Code specific rule 

IS = specific ICD code rule 

IC = multiple ICD to category rule 

lA = ICD to age rule 

EG = ICD to gender 


Rule Identifier 


Alpha/Numeric 


4 


assigned from Qualifying Master Table 


Indicator 


Alpha/Numeric 


2 


I = Index code 

R = Related 

S = signs/symptoms 

RO - Rule out 

M = Miscoded 

V = Vcodes 

MI = Miscoded Index 

or Blank 


Code 


Alpha/Numeric 


5 


category, CPT, HCPCS, ICD or blank 


Update 


Character 


1 


A, C, or Blank 



Total 14 
USE: 
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• To act as a qualifying mechanism for detemiining if claims information can be 
used in the assignment of an EOC 

• This table interrelates with: 

- Procedure Table 

- Category Table 

- Qualifying Group Table 

- ICD Description Table 

- Index Detail Table 

QUALIFYING CODE TABLE 

Table houses quaUfying circumstances based on the presence or non- 
existence of a specific combination of procedure codes that would qualify or disqualify 
a patient history in the determination of an Episode of Care. 



Rule Type 


Alpha/Numeric 


2 


CC = Multiple code rule 
CS = code specific rule 


Rule Identifier 


Alpha/Numeric 


4 


As labeled in Qualifying Master Table 


Primary code 


Alpha/Numeric 


5 


CPT, HCPCS or category or ICD 


Secondary Code 


Alpha/Numeric 


5 


CPT, HCPCS or category or ICD 


Update 


Character 


1 


A, C, or Blank 



Total 14 
USE: 



• To act as a qualifying mechanism for determining if claims information can be 
used in the assignment of an EOC. 

• This table interrelates with: 

- Procedure Table 

- Category Table 

- Qualifying Group Table 
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SPECIALTY TABLE 



Table provides a listing of medical specialties with an assigned numeric 

identifier. 



Specialty (Key) 


Alpha/Numeric 


3 


Medicare specialty indicator 


Beg-CPT 


Alpha/Numeric 


5 


Beginning CPT to include 


End-CPT 


Alpha/Numeric 


5 


Ending CPT to include 


Update 


Character 


1 


A, C. or Blank 



Total 14 
USE: 



This table is used to specify which Specialty is most commonly used 
with which CPT. 

A description of the specialty will be in the documentation. 

ZIP/REGION TABLE 



Table provides a listing of geographical zip codes sorted into 10 regional 
zones, standard HCFA information. 



Region Indicator 


Alpha/Numeric 


2 


Medicares Ten Regions 


Beg-Zip Code 


Numeric 


5 


Beginning Zip Code Range 


Beg-Zip Code 


Numeric 


5 


Ending Zip Code Range 


Update 


Character 


1 


A, C, or Blank 



Total 13 
USE: 



This table is used to specify which Medicare Region to use for the 

statistic table. 
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SPECIALTY STATISTIC TABLE 



Table provides a listing of medical specialties with an assigned numeric 

identifier. 



Index Code 


Alpha/Numeric 


5 


Left justified assumed decimal after 3rd 
position. 


Specialty 


Alpha/Numeric 


3 




Beg-CPT Code 


Alpha/Numeric 


5 


Beginning Range (Service Area) 


Beg-CPT Code 


Alpha/Numeric 


5 


Ending Range (Service Area) 


Category 


Alpha/Numeric 


4 


Mnemonic 


Multiplier 


Numeric 


6 


Implied decimal (4.2) 


Update 


Character 


1 


A, C, or Blank 



Total 29 
USE: 



This table is a matrix that is directly tied to the parameter table by the 
index code. Its purpose is to give a numeric multiplier that is applied to the occurrence 
field in the parameter table, to vary the parameter by service area and/or sex and/or 
region, (i.e., if the occurrence is 2 and the multiplier for a specialist is 1 .5, the specialist 
may receive a total of 3.) Multiple multipliers may be applicable to each parameter. 

AGE/GENDER STATISTIC TABLE 



Table provides a Usting of each CPT code for an index code v^ith a 
numerical factor used to adjust the frequency of each code by age and/or gender specific 
data analysis. 



Index Code 


Alpha/Numeric 


5 . 


Left justified assumed decimal after 3rd 
position. 


Age 


Alpha/Numeric 


2 


00-99 


Sex 


Alpha/Numeric 


1 


M, F or Blank 


Category 


Alpha/Numeric 


3 


Mnemonic 


Multiplier 


Decimal 


6 


Implied decimal (4.2) 


Update 


Character 


1 


A, C, or Blank 



Total 18 
USE: 
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This table is a matrix that is directly tied to the parameter table by the 
index code. Its purpose is to give a numeric multiplier that is applied to the occurrence 
field in the parameter table, to vary the parameter by service area and/or sex and/or 
region, (i.e. if the occurrence is 2 and the multiplier for a male is 1.5, the male may 
receive a total of 3.) Multiple multipliers may be applicable to each parameter. 

REGION STATISTIC TABLE 



Table provides a listing of CPT codes for an index code with a numerical 
factor used to adjust the frequency of each code by regional data analysis. 



Index Code 


Alpha/Numeric 


5 


Left justified assumed decimal after 3rd 
position. 


Region 


Alpha/Numeric 


2 


Medicares Ten Regions 


Multiplier 


Decimal 


6 


Implied decimal (4.2) 


Update 


Character 


1 


A, C, or Blank 



Total 14 
USE: 



This table is a matrix that is directly tied to the parameter table by the 
index code. Its purpose is to give a numeric multiplier that is applied to the occurrence 
field in the parameter table, to vary the parameter by service area and/or sex and/or 
region, (i.e., if the occurrence is 2 and the multiplier for a region is 1.5, the region may 
receive a total of 3.) Multiple multipUers may be applicable to each parameter. 

FILE LAYOUT FOR CLAIMS DATA CONTRIBUTION 

We prefer Electronic Media Claims National Standard Format; however, 
if you are not using EMC the following is our suggested layout. Please include an exact 
layout of the format you use with your submission. The record layout that follows is for 
each hne item that appears on a claim. The charge (field 19) should be the non- 
discounted fee-for service . There should be no aggregation or fragmentation. 
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Field 






Alpha/ 




Number 


Description 


Length 


Numeric 


Comments 


1. 


Rendering Provider ID 


15 


A/N 


Unique provider identification number or 
SSN 


2. 


Billing Provider ID 


15 


A/N 


Unique provider identification number or 
SSN 


3. 


Provider Specialty 


3 


A/N 


Supply a List of Specialty codes used 


4. 


Patient ID 


17 


A/N 


Unique patient ID number or SSN. May be an 
encrypted or encoded format. 


5. 


DOB 


6 


N 


Patient Date of Birth MMDDYY 


6. 


Sex 


1 


A 


M = Male, F = Female 


7. 


Subscriber ID 


25 


A/N 


Insured's I.D. No., Normally SSN 


8. 


Relationship 


1 


N 


Patient to Subscriber, 1 = Self, 2 ^ Spouse, 3 
= Dependent 


9. 


Bill ID 


15 


A/N 


Unique claim/bill identification number 


10. 


From Date of Service 


6 


N 


MMDDYY 


11. 


To Date of Service 


6 


N 


MMDDYY 


12. 


Provider Zip 


5 


N 


Standard 5 digit Zip Code 


13. 


Place of Service 


2 


A/N 


Supply a list of POS codes used 


14. 


Type of Service 


2 


A/N 


Supply a list of TOS codes used 


15. 


Procedure Code 


5 


N 


Submitted CPT or HCPC code 


16. 


Modifier 


2 


N 


Submitted CPT modifier 


17. 


2nd Modifier 


2 


N 


If multiple modifiers are submitted, show the 
second modifier used. Anesthesia Modifiers 
(P1-P6) 


18. 


Claim type 


3 


A/N 


Payor Class Code-W/C, HCFA, Medicaid etc. 


19. 


Charge 


5 


N 


Billed amount, right justified, whole dollars 


20. 


Allowed Amount 


5 


N 


Right justified, whole dollars 


21. 


# of days/units 


5 


N 


number of days and/or units 


22. 


Anesthesia time 


3 


N 


Actual Minutes 


23. 


ICDl 


5 


A/N 


First diagnostic code attached to procedure 


24. 


ICD2 


5 


A/N 


Second diagnostic code attached to procedure 



(Both ICDl & ICD2 are left justified, 
assumed decimal after 3rd byte) 
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25. ICD3 5 A/N Third diagnostic code attached to procedure 

26. ICD4 5 A/N Fourth diagnostic code attached to procedure 

27. Out-patient facihty 5 A/N Outpatient facility/outpatient hospital 

identifier 

28. Revenue Code 3 N Revenue center code 

ACCEPTABLE MEDIA TYPES 

* 9 track tape: 1600 or 6250 BPI, ASCII or EBCDIC, Labeled or Unlabeled, 
Unpacked data, Fixed record lengths 

* Floppy disk; 3.5'* (L44Mb or 720K) or 5.25" (1.2Mb or 360K), Standard MS- 
DOS formatted disk, ASCII fixed record length or delimited file 

* DC 600A or DC 6150 cartridge : "TAR" or single ASCII or EBCDIC file, 
Unpacked data, Fixed record lengths 

* 8 mm Exabyte tape: "TAR" or single ASCII or EBCDIC file. Unpacked data, 
Fixed record lengths 

* 3480 cartridge: Unpacked data, Fixed record lengths, Compressed or 
Uncompressed 

* Maximum Block size 64,280 



DATA PROCESSING METHODOLOGY 

This invention is a process for analyzing healthcare providers' billing 
patterns to assess utilization patterns of medical services. The method of the invention 
incorporates a set of statistically derived and clinically vaUdated episode of care data to 
be used as a paradigm for analyzing and comparing providers' services for specific 
diagnoses or medical conditions. This invention utilizes a series of processes to analyze 
the client's healthcare claims history to create unique parameters. In its preferred 
embodiment, the invention is implemented in softv^are. The invention provides the 
foUow^ing functions or tools to the client: creation of local profiles, display of profiles 
and comparison of profiles. 

The creation of local profiles function gives the cUent the ability to 
develop unique episode of care profiles utilizing their own claims history data. The 
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process for creating these profiles is identical to the process used in the development of 
the reference profiles. 

The display of profiles function provides a look-up capability for 
information stored in the reference tables or in client generated profile tables. This 
look-up capability may be displayed on the computer screen or viewed as a hard-copy 
printout. 

The comparison of profiles function provides a comparison between any 
two profile sources with attention to variance between them. Some examples include 
comparing cUent specific profiles to reference tables, comparing a specific subset of the 
cUent's data (eg, single provider) against either reference tables or the client's profiles, 
or comparing different subsets of the client's profiles to subsets of reference tables. 

There are four main processes involved in the invention, as depicted in 
FIG. 10. These are Read, Analyze and Merge (RAM), 1001, further depicted in FIG. 
11; Episode of Care analysis (EOC), 1002, further depicted in FIG. 12; Look-up 
fiinction, 1003, further depicted in FIGS. 13 and 14; and Profile Comparison, 1004, 
further depicted in FIG. 15. The invention also includes an innovafive reporting 
mechanism. Each of these four main processes and the reporting mechanism is 
described in detail in the remainder of this section. 

A. Transforming Raw Data Into an Informative Database 

Both the RAM and the EOC processes involve healthcare claims history 
search and analysis. The intent of the RAM and the EOC claims history processing is to 
enable the end user to estabHsh their own unique profiles based on their existing claims 
data information. Developing a database of historical provider billing data which will 
be used to provide the functionality of the invention is the first step in the invention. 

1. Read, Analyze and Merge ("RAM") 

In order to define a profile a significant quantity of historical medical 
provider billing information must be analyzed. As indicated above, the provider 
billings may come from a variety of sources, with the general guideline that accuracy 
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and completeness of the data and a statistically significant sample of provider billings 
are required to develop a reliable profile. In the preferred embodiment of the invention, 
no less than two years of consecutive claims history are used to develop the profiles. 
The RAM process verifies existence and validity of all data elements in a claims history 
before the data is processed to develop a profile. The reader is directed to FIGS. 1 and 
6-8 for pictorial representations of the preferred embodiment of the invention. FIG. 1 
depicts the high level steps performed in one embodiment of the invention. The data 
flow shown in FIG. 1 includes loading client data 101 fi^om tape 100, reordering various 
fields 103 and performing date of service expansion 104 as necessary. Next, data are 
merged (combined) 1-5 and sorted 106 to ensure all bill IDs are grouped together. The 
data 108 are then read, analyzed and merged into an extended data set (EDS) 1 10. 
Reporting and any other processing may occur 1 1 1 and an Episode of Care database 112 
is created. In the preferred embodiment of the invention, the steps of the invention are 
implemented in a software product referred to as Care Trends available fi-om Medicode, 
Inc. of Salt Lake City, Utah. 

FIG. 6 depicts read, analyze and merge processing that occurs in the 
preferred embodiment of the invention. First, one claim at a time the data 603 are read 
601, crosswalked and scrubbed (filtered) 602. Then a claim is analyzed 604 with the 
results output to a log file 605. The resuhs in the log file 605 are then compared 606 to 
the original claim data and inserted 607 into an extended data set 608. 

FIG. 7 depicts an analytical process of the preferred embodiment that 
includes initializing 701 RVU and line number for each line of the claim and sorting 
702 by RVU (descending) and CPT and charge in order to prepare for proper analysis 
by Medicode's Claims Edit System (CES). Then 703 line items are split into two 
groupings of surgical assistant modifiers and all other modifiers in separate groups. 
Each of the two groups is then vaUdated 704 against disease classificafion codes (ICD 
9); procedure edits rules 705 (CES tables) and unbundle/rebundle edits 706 are 
performed. 

FIG. 8 depicts the merge process of the preferred embodiment of the 
invention. It includes reading 802 each line fi-om the log file for the current bill, 
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proceeding with processing if the record read is pertinent 804 and determining whether 
to add the record to the extended data set 805-807. 

The following text includes a written description of the RAM processing 
that is performed in the preferred embodiment of the invention. FIG. 1 1 shows the 
RAM process. 

The first step in the RAM process is determination of a patient record, 
1101. It is necessary to establish a patient record that can be used in the episode of care 
extraction process (explained in detail below). In the preferred embodiment, a patient 
record is identified as a unique patient history involving no less than two years of 
sequential claims history. Because identifying patient information is often removed 
from patient records to ensure patient confidentiality, patient information such as 
subscriber/relationship, patient ID, age, gender, bill ID and claim ID may be useful in 
positively identifying a particular patient. It should be noted that claims history data 
from various sources may need to be handled differently to identify patient records due 
to differences in file organization and level of detail of information provided. The 
amount of information desired to be captured may vary in different embodiments of the 
invention, but generally the information to be captured is that on a standard HCFA 1500 
billing form, Electronic Media Claims, UB 82 or UB 92 claim forms, all of which are 
generally known in the industry. 

The next step, 1 102, is the manipulation of the client file layout to 
extrapolate or crosswalk the pertinent information in order to conform to the logic of the 
invention. Examples of this step include: translation of type of service, specialty type, 
modifiers, and/or place of service information. 

The next steps involve the validation of claims elements. Each line item 
of claims history is compared against the Procedure, Description tables, (such as CPT or 
HCPCS description tables; such tables generally are referred to as Description Tables 
and may contain any coding schemes) and the ICD description tables to validate the 
codes contained in the line item, 1 103. Line items with an invalid code are not included 
in the remainder of RAM processing, though they are counted for future reference. Line 
items which indicate services being performed over a period of more than one day are 
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expanded into numerous line items, one for each service performed, 1 104. The services 
are then each given a unique date of service beginning with the "date of service from" 
for the first line item and ending with the "date of service to" for the last line item. The 
last validation step, 1 105, is the conversion of old CPT codes to new CPT codes. This 
step is essential to provide the most accurate statistics relative to physician office and 
hospital visits (termed Evaluation and Management Services). 

The last step of the RAM process is to edit all claims for errors, through 
an appropriate claims edit tool, 1 106. Li the preferred embodiment, software known as 
"CLAIMS EDIT SYSTEM" which is available from Medicode, Inc. located in Salt 
Lake City, Utah is used to detect and correct any duplicate line items or inappropriately 
billed services. This results in an appropriately processed set of raw data that is now in 
a condition for episode of care processing. The reader is directed to the RAM source 
code in the Microfiche Appendix for all details of this processing performed in the 
preferred embodiment. 

Figure 9 depicts episode of care formation in the preferred embodiment. 
This processing includes processing the records in the extended data set that relate to the 
current index code. This relation is determined by the index tables. Then the records 
are broken into potential episodes of care based on a period of time specified in a 
window table. Then the episode of care is qualified based on the rules in a qualifying 
table. Qualifying episodes of care are inserted into the episode of care table. 
2. Determination of Episode of Care 

The next step in transforming raw data into a useful database is to 
determine episodes of care for the data that has already undergone RAM processing. In 
the invention, a database is created which contains profiles for various diagnoses, 
chronic and otherwise, including compUcations indicators. Creation of the database 
depends on accurately defining an episode of care ("EOC") for each diagnosis. An 
episode of care is generally considered to be all healthcare services provided to a patient 
for the diagnosis, treatment, and aftercare of a specific medical condition. The episode 
of care for a single disease is depicted in FIG. 2. In the simplicity of the figure, it can 
be seen that for the diagnosis in question, all healthcare services provided between onset 

33 

Marked up version of Second Substitute Specification showing changes to Specification of record. 
TO BE USED FOR ILLUSTRATION PURPOSES ONLY 



and resolution should be incorporated into the database. An example of this would be a 
patient who has been afflicted with acute appendicitis. The patient's life prior to onset 
of the acute appendicitis would be considered a disease free state. On some date, the 
patient would notice symptoms of acute appendicitis (although he may not know the 
diagnosis) that cause him to seek the attention of a medical provider. That event would 
be considered the onset. During the disease state, numerous events may occur, such as 
the patient consulting a family practitioner, consulting a surgeon, laboratory work and 
surgical services being performed, and follow-up visits with the provider(s). When 
further follow-up is no longer required, resolution has been reached. Thus an episode of 
care has been defined and data from that patient's episode of care is used in the 
invention to construct a profile for the diagnosis applicable to that patient. Without the 
use of additional logic, however, the use of that definition of an episode of care would 
result in erroneous data being entered into the EOC database. 

For example, in FIG. 3 it can be seen that a patient suffering from a 
chronic disease who contracts a second disease could be treated both for the chronic 
disease and for the second disease during the disease state (i.e. between onset and 
resolution). If all medical provider biUing data during the disease state were entered 
into the database, then the database would contain erroneous historical data for that 
individual's diagnosis. For example, if a patient who suffers from psoriasis were to be 
diagnosed with acute appendicitis and received treatment for psoriasis between the time 
of onset and resolution of his acute appendicitis, then the provider billings would 
contain both billings for treatment of the psoriasis and the acute appendicitis. Therefore 
the invention incorporates methods for discerning medical provider billings relevant to a 
particular diagnosis. Further, the disease state could be the active state of a chronic 
disease, and resolution could be the disease retuming to its inactive state. A method for 
handling this situation is therefore also provided. 

Other alternatives in the course of a disease further complicate accurately 
defining an episode of care. From FIG. 4 it can be seen that for any particular 
diagnosis, the outcome could be resolution, as described above, return to the chronic 
state of a disease, or complication of the disease. For example, if a patient has 
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undergone an appendectomy, the patient may contract an infection following the 
surgical procedure. Because complications of various types and durations and in 
varying frequencies are associated with various diagnoses, a method for incorporating 
the complication data into the statistically-derived practice parameter is intended to be 
provided in the invention. 

FIG. 5 depicts the phases of an episode of care, including the sequence of 
patient workup, treatment, and eventual solution, return to the chronic state, or 
complication followed by either resolution or return to the chronic state. 

The method for defining an entire episode of care provided in the 
invention is used to construct a database of EOCs based on billing data that has been 
filtered to eliminate data irrelevant to the diagnosis which would lead to an erroneous 
profile. Essential to the determination of an EOC are certain qualifying circumstances. 
These circumstances are managed through the use of interrelational qualifying tables, to 
provide a mechanism for sorting patient history for the occurrence of specific 
procedures or ICD codes that are requisite for an EOC to be valid. 

The steps used in the preferred embodiment to determine an episode of 
care are shown in FIG. 12 and as follows, 
a.) Data Sort by Index Code 

First, \i-2QS] 1201 , a temporary file is created based on combining the 
authorized and/or disallowed ICD codes that are associated with a given index code in 
the Index Global Table (listing preventative and aftercare codes) and the Index Detail 
tables. The temporary file is created using the Index Table, which determines whether 
or not the Index Detail Table only should be accessed or whether the Index Global 
Table is also necessary for drafting the temporary file. Second 1202, the raw data set 
which has undergone RAM processing is sorted by index code (i.e. [principalJ-generaL 
diagnosis) to find all patient records within a patient history having an occurrence of a 
particular index code. It is contemplated that the number of occurrences of a particular 
index code can be defined by the user. In the present embodiment, it is recommended 
that the particular index code being sought occur on at least two different dates of 
service. [Thirdy-t20^,~-th©] The valid components of these patient records are then 
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checked against the interrelational quahfying tables to identify ICD codes associated 
with the chosen index code. The quahfying circumstances identify criteria such as 
procedures relating to specific medical conditions which may have been indicated as 
usually requiring an Evaluation and Management (E/M) service during the course of 
treatment. For example, an occurrence of a qualifying circumstance such as an E/M 
service during the patient history is considered in the criteria of an episode of care. In 
addition, the patient records are searched for any rcomorbidit-yl- complicating ICD codes 
that would disquahfy the patient record for inclusion in the EOC (such as diabetes or 
renal failure). 

Fourth, 1203 the patient records are compared against the interrelational 
quaUfying tables to ensure comphance with all patient-level qualifying rules. Patient 
records that fail to qualify are no longer considered for EOC evaluation for this Index 
Code, however, they may still quahfy for other Index Code analysis. Fifth, 1205 all 
relevant line items for every remaining patient record are checked against the temporary 
file created in step one for complicating diagnosis codes. Any patient record thus 
identified with a complicating diagnosis code is removed from further EOC processing. 

b.) Determination of Clear Windows 

Clear window processing defines the onset and resolution points of an 
episode of care. The actual parameters used in clear window processing may vary in 
various implementations of the invention. A clear window time period is selected for 
the specific Index Code from the window table 1206. Next, 1207 proceeding 
chronologically, each record is compared with the record immediately preceding it. The 
first record read defines the beginning event of an initial episode of care and the last 
record read defines the terminating event of a final episode of care. If the two records 
being compared are separated by a time period equal to, or greater than, the clear 
window the earlier record is identified as the terminating event of the earlier episode 
and the later record is identified as the beginning event of the next episode. 
Accordingly, the initial episode of care and the final episode may be the same episode 
of care. It is also possible, for the first record and the last record to be the same record. 
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This iterative process is continued for all remaining records for all patient claims. In 
this fashion potential EOCs are identified within the patient claims, 
c.) Valid Episode of Care 

Each potential episode is then checked to determine if the index code in 
question appears on the required number of dates of service within the EOC 1208. If 
the index code does not appear the required number of times, the potential EOC is 
pended. The qualifying tables are then checked to determine if the potential EOC meets 
the minimum criteria for procedure codes (such as surgical services) that are expected to 
be found within a potential episode of care for a given index code. If the minimum 
criteria are not found in an episode of care, it will not be considered in the profile 
summary. Processing continues for all patient records. Once an EOC has been 
determined for a set of claims history meeting the criteria for an Index code, a profile is 
assigned to the EOC based upon different combinations of treatment patterns that are 
likely to arise for a given medical condition, 1209. There are eight basic profile classes 
which outline the common combinations of treatment pattems to statistically analyze 
and store. These Profile Classes are: 

0. Common Profile (diagnostic and E/M services common to all of the 

above). 

1 . Surgery/Medicine/Radiation Profile 

2. Medicine/Radiation Profile 

3 . Surgery/Radiation Profile 

4. Surgery/Medicine Profile 

5 . Radiation Profile 

6. Medicine Profile 

7. Surgery Profile 

8. Summary Profile (summary of 0-7 above) 

After all valid EOCs have been assigned to a unique profile processing 
continues with population of the procedure and category tables. 
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d.) Populating the Procedure and Category Parameter Tables 

The data from qualified EOCs will be added to the procedure and 
category parameter tables 1210. Data from all of the episodes of care for each index 
code are inserted into the parameter tables to create the summary statistical profiles. In 
the preferred embodiment these tables are accessed by index code and populated with 
data from all the episodes of care for each index code to create and provide summary 
statistics. The procedure description table and category table are also accessed to 
determine a description of the procedure codes and the service category in which they 
fall. 

The final step of the EOC process is the generation of output reports, 
1211. The output report of this step can be either an online look-up report or a hard 
copy report. Reports are further described below. 

The reader is directed to the Microfiche Appendix containing the source 
code for EOC processing and to FIG. 9 for supplementary information. 
B. Use of the Database 
1. Look-up Function 

In the preferred embodiment of the invention, a look-up function is 
provided so that various information available in the database may be accessed. In 
general, a specific diagnosis may be reviewed in each of the tables of the database based 
on ICD code. In various embodiments of the invention, other look-up functions may be 
provided based on nearly any category of information contained in the database. In the 
preferred embodiment of the invention display of profiles is performed as part of the 
look-up fiinction. Information in the procedure and category parameter tables are 
displayed by index code sorted chronologically to show a profile. 

The specific steps of the preferred embodiment of the Look-Up function 
of the invention are shown in FIG. 13 and described as follows. 

The first step, 1301, is to review the reference tables for a given Index 
ICD code. Once a specific diagnosis is chosen for review the process moves to step 
two. In step two, 1302, the ICD description table is accessed to verify that the ICD-9 
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code is valid, complete and to provide a description of the diagnosis. It will also 
indicate a risk adjustment factor assigned to the diagnosis. 

In step three, the Index tables are accessed, 1303. Next, step four, 1304, 
is to determine whether or not the chosen ICD code is an Index code. If it is found as an 
Index code, any additional ICD codes associated which the selected Index code will be 
accessed, 1305. If a chosen diagnosis is not Hsted as an index code, a prompt, 1306, 
will allow a search for the selected ICD code to list which index code(s) it may be 
associated with and its indicator, 1307. A word search capability, 1308, is included in 
the look-up function applicable to the Index code display. A word or words of a 
diagnosis is entered and a search of possible ICD codes choices would be listed. 

The next step, 1309, is to access the Parameter Tables to display selected 
profiles. The information provided is driven by the index code and is sorted 
chronologically, by profile class and by category of procedures. The user is then given 
the opportunity to choose whether the profiles to be accessed are fi:'om the reference 
tables, client developed profiles, or both, 1310. Next the Procedure Description Table, 
1311, and the Category Table, 1312, are accessed to ascertain description of procedure 
codes and categories under which they fall. 

The last step of the Look-Up function is the output of report product, 
1313. This report may either be on-line look-up process or in the hard copy report 
format. 

The preferred embodiment of the invention also performs subset profile 
look-up. This permits analysis of profiles based on selected subsets of data such as age, 
gender, region and provider specialty. 

The process for the subset of profiles look-up includes all of the steps 
necessary for the general profiles look-up and includes the following additional steps 
shown in FIG. 14 and described below. 

The Age/Gender Table is accessed to ascertain the standard age ranges 
and/or gender selection for a given profile, 1402. This information is stored by index 
code with an adjustment factor to be multiplied against the occurrence count of each 
procedure stored in the parameter table. For example, an adjustment factor of 0.6 
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associated with an age range of 0 to 17 would be calculated against an occurrence count 
of 10 for CPT code 71021 for Index code 493XX giving an age adjusted occurrence of 6 
for that age range. 

The Region Statistic Table, 1403, is accessed and used in a similar 
manner as the Age/Gender Table. This table has adjustment factors based on ten 
regions throughout the United States. 

The Zip/Region Table, 1404, is accessed to identify what region a 
particular geographic zip code falls within. 

The CPT Statistic Table, 1405, is accessed and used in a similar manner 
as the Age/Gender table. This table has adjustment factors based on different medical 
specialty groupings. 

The Specialty table, 1406, is accessed to ascertain what particular 
specialty groupings are suggested. 

The subset parameter Look-Up function also includes the capability of 
producing output reports, 1407. These reports can be on-line look-up process reports or 
hard-copy report format reports. 

2. Comparison Processing 

In the preferred embodiment of the invention, it is possible to compare 
profiles developed fi-om a data set against profiles developed from a reference data set. 
Subsets of profiles may be compared as well. Profiles may be compared for any index 
code and profile reports may be output. It is also possible to identify those medical 
providers (whether individuals or institutions) who provide treatment that does not fall 
within the statistically established treatment patterns or profiles. Further, various 
treatment patterns for a particular diagnosis can be compared by treatment cost and 
patient outcome to determine the most effective treatment approach. Based on 
historical treatment pattems and a fee schedule, an accurate model of the cost of a 
specific medical episode can be created. 

The specific process of Comparison Processing is shown in FIG. 15 and 
described as follows. The first step, 1501, is the comparison of information developed 
from the data history search process with reference information stored in the Parameter 
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Tables. The next step, 1502, is to test the services from the history processing to see if 
it falls within the defined statistical criteria in the Parameter Tables. If it does an 
indicator is given to this effect, 1504. If the services fall outside the statistical criteria of 
the reference Parameters Table, a variance alert describing the difference w^ill be given, 
1503. The process may be repeated for each index code and its profile developed in the 
history process, 1505. The final step is to produce output reports, 1506. These reports 
are either on-line look-up process reports or hard-copy report format reports. 
3. Reporting 

Reporting of various information contained in the database is provided in 
the preferred embodiment. Six different types of reports or displays are provided in the 
preferred embodiment, these are: Provider Practice Profile Report, Profile Comparison 
Reports, Resident Parameters Display, Local Parameters Display, Parameter 
Comparison Report and Chronological Forecast. Each of these reports or displays is 
described as fdllow^s. 

The Provider Practice Profile Report is a set of reports which provide a 
tally or summary of total CPT and/or ICD code utilization by a provider or group of 
providers during a specified time interval and allows comparison against provided 
reference data or client generated reference data. 

The select criteria for rurming the tally can be any one of the following: 

- single physician, department, specialty or clinic by CPT and/or ICD 

- multiple physicians, departments, specialties, or clinics by specialty, 
region, CPT and/or ICD 

- period of time being analyzed 
Included in the report is the following: 

- criteria for select 

- claims analyzed 

- average lines per bill 

- invaHd CPTs and percent of total for study 

- invalid ICDs and percent of total for study 

- incomplete ICDs and percent of total for study 
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- patients in age categories 

- patients by gender 

- missing ICDs and percent of total for study 

The report includes numerous (up to about 22 in the preferred 
embodiment) separate procedure (such as CPT) categories which are headers for each 
page. Each CPT utihzed within that category will be reported by: 

- frequency and percent of total 

- dollar impact and percent of total for single or multiple fee schedules 
and/or allowable reimbursement schedules 

- grand total if more than a single physician report 

The report includes a tally by ICD. Each ICD utiUzed is reported on by: 

- frequency and percent of total 

- dollar impact and percent of total for single or multiple fee schedule 
and/or allowable reimbursement schedules (dollar impact based on 
each line item CPT correlated to the ICD) 

If a report includes region and/or specialty, there are numerous tallies for 
procedure categories and/or ICD. 

The Profile Comparison Reports give the client a comparison of a health 
care provider's (or group of providers') utilization of CPT and/or ICD-9 codes in a 
specific episode of care against a reference set of utilization profiles. This includes 
number, frequency and chronological order of services along with other statistical 
information (eg, range, mode, confidence interval, etc.). 

The comparison can be against one of the following: 
national norms resident in the tables 

- regional norms resident in the tables 

- cUent established norms developed by use of the tally report, outlined 
above 

- other 

Selection criteria include the following: 
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- single physician, department, clinic or specialty by CPT and/or ICD 
to be compared against national, regional, specialty, and/or client 
established norms 

- multiple physicians, departments, clinics, or specialties by CPT 
and/or ICD by specialty and/or region, to be compared against 
national, region, specialty, and/or client established norms 

set period of time being analyzed 
General information included in the report includes: 

- criteria for select (i.e., national, regional, specialty, and/or client 
estabUshed) 

claims analyzed 
average lines per bill 

- invalid CPTs and percent of total for study and comparison 

- invalid ICDs and percent of total for study and comparison 

- incomplete ICDs and percent of total for study and comparison 
patients in age categories and comparison 

- patients by gender and comparison 

- missing ICDs and percent of total for study and comparison 

The report includes numerous separate CPT categories which are headers 
for each page. Each CPT utilized within that category will be reported by: 
frequency and percent of total 

- dollar impact and percent of total for single or multiple fee schedules 
and/or allowable reimbursement schedules 

grand total if more than a single physician report 
The report includes a tally by ICD. Each ICD utilized is reported on by: 
frequency and percent of total 

- dollar impact and percent of total for single or multiple fee schedule 
and/or allowable reimbursement schedules (dollar impact based on 
each line item CPT correlated to the ICD) 
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If a report includes region and/or specialty, there are numerous tallies for 
CPT categories and/or ICD. 

The Resident Parameters Display provides the client a look-up mode for 
information stored in the Practice Parameter Tables or client generated parameter tables. 
This lookup should be on the computer screen or as a print out. 

The selection criteria is based on the key elements of the Practice 
Parameter tables. For Example: 

- Index code for associated CPT codes and/or any other the following: 

- index code only 

- index code and indicators (i.e, related, complicating, rule/outs, 
symptoms, etc) 

- specialty 

- region 

- age 

- gender 

- standard length of Episode of Care 

- based on profile (tally) 
based on parameter (timeline) 

- regional variables 

- other misc. look-ups 

geozips incorporated in a region 

- CPT for follow up days and/or lifetime occurrence 
specialty and associated CPT codes 

- ICD and Risk Factor 

The Local Parameters Display provides the same information as 
described in the Display of Resident Parameters listed above. 

The Parameter Comparison Reports are a set of reports which give the 
cUent a comparison of a physician (or group of physicians) utiHzation of CPT and/or 
ICD against an existing set of utilization norms over a timeline and in chronological 
order. 
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The comparison can be against one of the following: 
national norms resident in the tables 
regional norms resident in the tables 

- client estabhshed norms developed by use of the tally report, outlined 
above 

- other 

Selection criteria include the following: 

- single physician, department, clinic or specialty by CPT and/or ICD 
to be compared against national, regional, specialty, and/or client 
established norms 

- multiple physicians, departments, clinics, or specialties by CPT 
and/or ICD by specialty and/or region, to be compared against 
national, region, specialty, and/or client established norms 

set period of time being analyzed 
General information included in the report includes: 

- criteria for select (i.e, national, regional, specialty, and/or client 
established) 

claims analyzed 
average lines per bill 

invalid claims due to incomplete Episode of Care 

invalid CPTs and percent of total for study and comparison 

- invalid ICDs and percent of total for study and comparison 

- incomplete ICDs and percent of total for study and comparison 

- patients in age categories and comparison 
patients by gender and comparison 

missing ICDs and percent of total for study and comparison 
The report includes numerous separate procedure categories which are 
headers for each page. Each procedure category utilized within that category will be 
reported by: 

frequency and percent of total 
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- dollar impact and percent of total for single or multiple fee schedules 
and/or allowable reimbursement schedules 

- grand total if more than a single physician report 

The Chronological Forecast provides statistical trend analysis and 
tracking of the utilization of billing codes representative of services performed by a 
physician for a given diagnosis over a set period of time and stored in chronological 
order. It will provide a summation of billed codes representative of services and 
diagnoses utiUzed by an entity over a period of time. 

C. System Requirements 

The method and system of this invention may be implemented in 
conjunction with a general purpose or a special purpose computer system. The 
computer system used will typically have a central processing unit, dynamic memory, 
static memory, mass storage, a command input mechanism (such as a keyboard), a 
display mechanism (such as a monitor), and an output device (such as a printer). 
Variations of such a computer system could be used as well. The computer system 
could be a personal computer, a minicomputer, a mainframe or otherwise. The 
computer system will typically run an operating system and a program capable of 
performing the method of the invention. The database will typically be stored on mass 
storage (such as a hard disk, CD-ROM, worm drive or otherwise). The method of the 
invention may be implemented in a variety of programming languages such as COBOL, 
RPG, C, FORTRAN, PASCAL or any other suitable programming language. The 
computer system may be part of a local area network and/or part of a wide area network. 

Referring to Fig. 16 of the drawings and to the Microfiche Appendix, there is 
illustrated a second embodiment of a method for implementing the present invention for 
determining episodes of care for a selected medical condition identified by an Index 
Code. This embodiment is essentially the same as that described above except where 
noted, and the same nomenclature and tables will be referred to as in the above 
embodiment. The method is implemented by the computer program module 
pp comp.4gl, which appears in the Microfiche Appendix. 
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a) Create Temporary File of ICD-9 Codes Corresponding to Selected Index Code 

First, at step 1610, a temporary file, tmp index, is created as a profflammin^ 
convenience, based on the Index Code for which episodes of care are being built. An 
Index Code identifies a medical condition (e.g„ 174? might be the Index Code for the 
disease. Malignant Neoplasm of Female Breast). In the Index Detail Table, each Index 
Code is associated with ranges of ICD-9 diagnosis codes relevant to the medical 
condition, as well as separate Indicator values associated with each range. Only ICD-9 
codes with an Indicator value of "I" or "MI" for the associated Index Code are used to 
drive the creation of an episode of care. 

At 1610, the pp compAsl module, after defining program variables, executes 
the function, IMake index, which builds the temporary file, tmp index, that contains a 
separate record for each ICD-9 code in the ranges of ICD-9 codes associated with the 
selected Index Code. (The value of the selected Index Code is passed to IMake index 
in the variable ir. index, which contains the Index Code value provided in the input 
record for pp comp.4^1, e.g., index detailindex) The fiinction call to the IMake index 
appears at the bottom of page 2 of the pp comp.4gl program listing. 

The IMake index fiinction creates the tmp index file by extracting from the 
Index Detail table and the Index Global table information that includes the ranges of 
ICD-9 codes associated with the selected Index Code and the Indicator value for each of 
such ICD-9 codes. For example, if, in the Index Detail table, Index Code 174? were 
associated with the following ranges of ICD-9 codes and Indicator values: 1740 to 1749 
for Indicator "I"; 174 for Indicator "MI"; 61 172 (Lump Or Mass In Breast) for 
Indicator "R;" then the tmp index file records correlating to Index Code 174? would 
include the following information: 



Indicator 


ICD9 


I 


1740 


I 


1741 


I 


1742 


I 


1743 
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1744 





1745 




1746 




1747 





1748 




1749 


MI 


174 


R 


61172 



a) Find Patients With Driving ICD-9 Codes 

Second, at step 1620, the raw data set that has undergone RAM processing is 

sorted by ICD-9 code to find all patient records having an occurrence of ICD-9 codes 

that may drive the creation of an episode of care for the selected Index Code (i.e., ICD-9 

codes corresponding to ICD-9 codes in the tmp index file having an Indicator value of 

"I" or "MI"). More specifically, the pp comp.4gl module first creates a second 

temporary file, tmp patient, with the following statement appearing at the top of page 

3 of the source code Usting. 

select unique patient^ relationship, sex 

from e line fcc, e claim cx, tmp index ix 

where ix.e claim id = cx.e claim id and 

IxJcdl = ixJcd9 and 

ixJndicator in CT\ ''MP') and 

cx.e claim id /= 0 

into temp tmp patient 

This statement creates the temporary table, tmp patient, and populates it with 
every unique combination of patient, relationship, and sex for every patient record 
containing an ICD-9 code listed in the tmp index table with an Indicator value of "I", 
or "MI". Since tmp index table maps Index Codes (medical conditions) to individual 
ICD-9 codes, the tmp patient table identifies only those patients whose diagnoses in 
their medical claims history include one of the driving ICD-9 codes for the medical 
condition in question. 

The program then creates a third temporary file, temp data, and populates it 

with every record from the RAM-processed data set that meets two criteria: 
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(1) contains a combination of patient, relationship, and sex values that 

corresponds with a record in the tmp patient table; and 

(2) contains an ICD-9 code that corresponds to an ICD-9 code in the tmp index 

table. 

The program statement that implements these two steps appears in the top half 

of page 3 of the pp comp.4sl program listing in the select statement beginning "select 

ex.*, ix.date of serv, ..." and ending with "into temp temp data" Specifically, the 

following segment of the select statement links the e claim table, which contains one 

record for each medical claim identified in the RAM-processed data set, to the 

tmp patient table described above by matching the patient ID number, relationship 

code, and gender values in the two tables. 

from e line be, e claim cx, tmp index £y, tmp patient ip 
where lx.e claim d=cx.e claim id and 

IxJcdl - ix,icd9 and 

cx.patient ~ ip.patient and 

cx.relationship = ip.relationship and 

cx,sex = ip,sex and 

Next, the following segment of the select statement links the e line table, which 
contains all records in the RAM-processed data set (that is, each claim line item that 
appears in the patients' medical histories), to the tmp index table described above by 
matching the ICD-9 diagnosis codes in the two tables. 

from e line Ix, e claim cx, tmp index ix, tmp patient ip 

where lx.e claim d=cx.e claim id and 
IxJcdl = ixJcd9 and 



The result of the foregoing two steps is that the temp data table will hold data 
that meet the following criteria: 

1. The claim line items belong to a patient who had an "I" or "MI" 
somewhere in their medical history. 

2, The claim line item includes an ICD-9 code that is also found in the 
temp index table. 
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At this point, the temp data table holds claim line items that potentially will be 
included in an Episode of Care (HOC) for a selected Index Code, 

a) Create Procedure Categorization Table 

At 1630, the program creates another temporary table, cat file that is used for 
grouping procedure codes into categories, which are described above in relation to the 
Category Table. The categories represent broad classes of treatment or service types, 
such as Major E and M (Evaluation and Management), Minor E and M, Major 
Diagnostic Radiology, Minor Diagnostic Radiology, Major Laboratory, and Major 
Therapeutic Surgery. Categories are used in place of individual procedure codes in 
subsequent program steps. For example, certain qualifying rules reference category 
codes rather than individual procedure codes. Also, categories are used to sort episodes 
of care into profile classes for analysis and reporting purposes. 

At step 1630, the program assigns a category mnemonic (e.g., E , for Major E 
and M) to each procedure code found in the temp data file. This program step is 
implemented by the source code at pages 3-4, beginning with the statement "call 
errorlog (^^Making Cat File^')," through the statement, "create unique index i catfl 
on cat file(proc);". Specifically, the cat file table is built by looping through each 
procedure code in the temp data table, finding every unique CPT/HCPCS code in that 
table and associating the code found with a category. 

b) Check Patient History Against Qualifying Rules 

At step 1640, the records from the patient histories (now in the temp data table) 
are reviewed to ensure compliance with the patient-level qualifying rules defined by the 
various qualifying tables of the present invention. Patient records that fail to qualify are 
no longer considered for EOC evaluation for the selected Index Code. The 
pp comp.4sl source code for implementing this step includes the statements beginning 
at the middle of page 4 with "declare upat curs cursor for" and continuing through 
the bottom of page 5, "execute del qual." Pertinent portions of these statements are 
reproduced below. 

foreach upat curs into q. * 

callqual checkC'P'') returning passed, eoc profile, rule err 
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if not passed then 

execute del temp data usins prev pat, prev reUprev sex 

end for each 

Generally, these program statements perform the following steps: 

• read fields from each patient record in the temp data table into upat curs; 

• for each patient record in upat curs\ 

> read the record into the variable set q, *; 

> call qual check function to determine if the patient data on the record 
satisfies a set of patient quaUfying rules, and 

> if not, remove all of the patient's data from further consideration for the 
selected Index Code. 

These patient qualification steps are repeated until such processing has been 
completed for all patients having a record in the temp data table. 

The Qual Check Function 

The qual check function identified above can be found beginning on page 13 of 
the pp comp.4sl program listing, beginning with the statement "function 
qual check(in scope)" and continuing through the end of page 16. For the selected 
Index Code, the qual check function loops through all entries in the qual master 
(Qualifying Master) table where the Scope field is equal to the value passed to the 
qual check function in the in scope variable. (In the present embodiment, the in scope 
variable is set to either the value "E" or "P", which indicates whether the function 
checks for 'E'pisode or T'afient level quahfying rules.) Here, at step 1640, the value of 
the in scope variable is set to T,' such that only patient level qualifying rules are 
executed. 

Based on the value of the Group field in the Qualifying Master table for the 
selected Index Code, the qual check function extracts qualifying rules information (i.e., 
Rule Type and Rule Idenfifier) from the qual group (Qualifying Group) table. More 
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particularly, when the qual check function reads a record from the qual master table 
for the selected Index Code, it uses the value of the rule ^roup field from the 
qual master record as a parameter to a query for reading a record in the qual group 
(Qualifying Group) table. Depending upon the value of the rule type field this 
qual group table record, the qual check function executes a different set of program 
statements implementing qualifying logic. As will be set forth more fully below, the 
qual check fimction uses this rule type value to extract information for identifying the 
proper qualifying rules from either the Qualifying Index table or Qualifying Code table, 
identified in the program listing as qual ic and qual cc, respectively. 

In the preferred embodiment described herein, the three values of the rule type 
field that trigger execution of qualifying logic are "11", "IC", and "CC". "IF'-type 
rules are qualifying rules specific to the Index Code and, for example, may require two 
or more occurrences of the Index Code in a patient history with different dates of 
service. "IC"-type rules define criteria for Index Codes relative to procedure (CPT) 
category codes. An "IC"-type rule identify CPT categories (not specific CPT codes) 
for the specific Index Code. "CC"-type qualifying rules are similar to "IC" rules, but 
instead of checking for a certain number of one type of procedure category, the "CC"- 
type logic checks for a single occurrence of each of two separate procedure categories. 

Pertinent portions of the qual check function are reproduced below. 

open mast curs usins in scope 

fetch mast curs into qm. * 

let hold status = status 

while hold status !- notfound 

open srp crs usin^ qm.rule sroup 

fetch srp curs into q^. * 

while status /= notfound 

when qm.rule type = ^7/^^ 
• • • 

when qm.rule type-''IC'' 

when qs.rule type-^^CC^^ 
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Thus, depending on the value of the rule type field, the program applies one of 
the sets of qualifying logic to determine whether a patient's record satisfies the 
appropriate set of qualifying rules for that patient. 

Type II Qualifying Rules 

The program logic for Type II qualifying rules begins by building a SQL query 
to check the patient record for a certain number of occurrences of specific codes (ICD-9, 
CPT, HPCPS or category) or Indicator values. The requisite number of occurrences of 
codes or Indicator values for the particular rule type is stored in the Number required 
field {q^.num required) of the Qualifying Group table. Upon execution of the query, 
and if the requisite number of occurrences is found, the qual check considers the 
patient to have successfully passed the Type II qualifying rules. 

More particularly, the Type II program logic builds a SQL query based on 
values read fi-om the qual ic table using the values of nz/e type dca^ rule /J read from 
the qual group table. If the cat cpt field of the qual ic record is populated (with a 
category, CPT, HCPCS, or ICD value), the where clause of the SQL statement is 
expanded to create a statement that checks for a match between the icdl field (from the 
tmp index table) and the value of cat cpt. If cat cpt is not populated, the where 
clause looks for a match between the indicator field in the tmp index table and the 
value read fi-om the indicator field in the qual ic table. This process continues for 
every record in the qual ic table containing the rule type value read from the 
qual group table. 

When no more records exist in the qual ic table for the given rule type, the 
SQL statement that was constructed is executed, and the number of records retumed is 
talUed. The total number of records satisfying the SQL query is then compared against 
the value of the nMffl regi/Zre J field firom the qual group table. If the total exceeds the 
value of the num required field, the rule is identified as having "passed''; if not, the 
rule is "failed". 

Next, the logical field fi-om qual group table is read. The logical field 
indicates whether the qualifying rule is inclusive or exclusive in nature. If the value of 
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the logical field is "F", the rule passed variable is inverted (that is, if the rule is 
exclusionary, and the requisite number of occurrences have been found, then rule v^as 
not "passed," and vice versa). Once this step is complete, the qual check function 
checks the rule passed value to determine whether to continue checking the patients' 
records for qualifying circumstances, or stop processing the patients' records and return 
control to the main program /yp compAsl- If the value of rt/Ze /^g^y^g^ for the patient's 
record is not "true", the qual check program exits and returns the rule passed value 
back to the section of pp compAsl code that called this qualifying logic. 

Type IC Qualifying Logic 

Similar to the Type II quaUfying logic, the Type IC logic initially reads a record 
fi-om the qual ic table using the rule type and rule id values previously retrieved from 
the qual group table. For each relevant record in the qual ic table, the program counts 
the number of records in the temp qual table v^here the category field matches the 
cat apt field value found on the qual ic record. This count is then compared against 
the num required field value fi"om qual group. If the count is greater than or equal to 
num required, the Type IC logic sets the rule passed variable to "true" (and, as was 
set forth above for the Type II logic, inverts its value where the value of the logical field 
is "F"). The qual check function then checks the rule passed value to determine 
whether to continue checking the patients' records for qualifying circumstances. If the 
value of rule passed for patient's record is not "true", the qual check program exits 
and the rule passed value is returned the main program. 

Type CC Qualifying Logic 

The Type CC qualifying logic differs from the Type II and IC logic in that it 

obtains its qualifying rule information from the qual cc (Qualifying Code) table rather 

than qual ic (Qualifying Index) table. For each record in qual cc matching the 

rule type and rule id fi-om qual group the following steps occurs: 

1. The number of records in temp qual where the category field matches the value 
in the cat cptl field from qual cc is tallied. 
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2. If this coxint is greater than or equal to 1, the number of records in temp qual 
where the category field matches the value in the cat cpt2 field from qual cc is 
tallied. If it is not, the Type CC code skips to the logic segment in step 4 
(below). 

3. If the count is less than the value of the num required field from qual group, 
the logical field from qual group is checked, and if the value of logical is "T", 
the passed variable is set to "false". The passed variable is also set to "false'' if 
the count is not less than the value of the num required field and the value of 
logical is "F." (If the count is not less than num required, the code skips to the 
logic in step 4.) 

4. If the passed variable is false, the section of code exits and passes control back 
to the area of the program that called this logic; otherwise the program checks 
for another relevant record in the qual cc table. 

5. When no more relevant records exist in qual cc, this section of code exits and 
retums control back to the area of the program that called this logic, returning 
the value of the passed variable to the main program (as in the Type II and Type 
IC logic segments). 

In each of the aforementioned qualifying logic segments, the qual check 
fiinction evaluates whether the qualifying logic is considered "passed" or "failed." If 
the rule is considered "failed," then the records for the patient currently being 
processed have been disquahfied for fiirther processing for the selected Index Code. 
The function continues processing with the next patient. When no more patients 
remain, the qual check fiinction retums control back to the main body of the 
pp comp.4sl wo^mi. 

a) Categorize Procedure Codes in Patient History 

Additionally, at 1645, as part oiXhQ foreach loop that calls the qual check 

fiinction, the program executes the following two statements appearing at the bottom of 

page 4 and continuing to page 5, which determine categories for the procedures codes 

appearing in each patient record and append a category code to the patient record: 

open set cat usin^ q.cpt 
fetch set cat into q. category 
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The category codes are used by the qual check function as part of qualifying 
patients for episode of care creation, at 1640, and sorting episodes of care into profile 
classes, at 1680, 

b) Use Clear Window To Identify Episodes of Care 

After processing each patient history against the applicable qualifying rules, the 
program, at step 1650, begins to build episodes of care for patient histories that did not 
fail the qualifying rules. A clear window time period delimits the onset and resolution 
of an episode of care. The clear window time period is selected for a specific Index 
Code from the Window Table. 

In the pp comp.4sl program, the function call on page 6 to report r edit begins 
clear window processing. 

finish report r edit 

The report r edit function (appearing on pages 8 and 9 and reproduced in 
pertinent part below) identifies the proper clear window time period, flags (for later 
processing) records indicating a medical complication, and then applies the clear 
window period to identify discrete episodes of care. 

report r edit (c, /, i, cur by) 
output 

order by c.patient, c relationship, csex, Ldate of serv 

select beg win into win max 

from window 

where statins in 

(select stasins from index where index = 

irJndex) 

First, report r edit function sorts the claim line item records by patient, 
relationship, sex and date of service. The report r edit function then determines the 
proper clear window period for the selected Index Code (which index corresponds to the 
ICD-9 codes appearing in the line item records now being processed). The bej^ win 
(Beginning Window) field of the window (Window) table defines the clear window 
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period, win max, that is, the maximum number of days without the occurrence of a 
service relating to a given medical condition (Index Code) that defines the beginning of 
a new episode of care. The report r edit function identifies the appropriate record in 
the Window Table firom which to extract the Beginning Window value by matching the 
Staging values in the Index Table record for the selected Index Code with the Staging 
Indicator in the Window Table record for the selected Index Code. In the Index Table, 
each Index Code is associated with a Staging value. In the Window Table, each unique 
combination of Index Code and Staging Indicator value is associated with a Beginning 
Window size. 

In addition, at 1655, patient records identified with a comphcating diagnosis 

code are tallied (and flagged to be removed firom EOC processing later, at step 1660). 

Specifically, in the following segments of the report r edit fiinction (on page 1 1 of the 

program listing), each line item for every patient record in the temp data table is 

checked for ICD-9 codes corresponding to an ICD-9 code having an Indicator value 

"C" (fi^om the tmp index table) and any such records are flagged. 

open cnt compile usin^ Licdl 
fetch cnt com;llc Into ok fla^ 
close cnt compile 

If ok flas then 

If not cur eoc Is bad then 

let eoc comp = eoc comp + 1 

let an eoc was bad - true 

let cur eoc is bad = true 

let cur status = 

end if 

end if 

Following the flagging of complications at 1655, the program then proceeds 
sequentially through the claim line item records in the temp data table (on a patient- 
by-patient basis) and identifies whether or not the applicable clear window period has 
expired between any two consecutive records. This algorithm uses the win max 
variable that was populated earlier in step 1650 with the proper Beginning Window 

value for the ICD-9 code on the record. The date of service in each record is compared 
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with the date of service in the record immediately preceding it chronologically. If the 

two records being compared are separated by a time period equal to, or greater than, the 

clear window period (win max), the later record is identified as the beginning event of 

the a new episode of care. This iterative process is continued for all remaining line item 

records for all patient claims and is implemented by the following segments of the 

report r edit function (appearing on page 11): 

ifldate of serv-prev dos>=win max then 
• • • 

leteoc cnt-eoc cnt + 1 

let cur eoc is bad = false 

let eoc cnt for pat = eoc cnt for pat + 1 

let cur eoc num = cur eoc num + 1 

let cur status = 

end if 

let prev dos = Ldate of serv 

An alternative embodiment, not implemented in the Microfiche Appendix, can 
employ a second process to delineate potential episodes of care. In such embodiment, 
the Window table is populated with values in both the Beginning Window and Ending 
Window fields. The Ending Window defines a post-episode clear window period, 
which may be different fi^om the pre-episode clear window (Beginning Window). In 
this manner, an episode of care can be defined relative to asymmetrical clear window 
time periods. 

In the present embodiment, after the program checks that the clear window 
period has not been exceeded, the claim line item is associated with a potential episode 
and inserted into the eoc table. Once all line items are so processed, the eoc table 
replaces temp data as the repository for all patient claims detail information and is 
used for all fiirther processing. 
c) Remove Patients With Complications 

At step 1660, the program removes from fiirther consideration patients having 

complications in their medical claims history, as indicated by a flag referred to above in 

step 1655. Namely, all records for patients flagged as having complications are deleted 

from the eoc table. This step is subsumed within the program statements for the report 
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r edit function. More particularly, the statement "put ins pat eoc" inserts the patient, 
relationship, and sex values for patients identified with complications into a temporary 
table, pat eoc, as specified in the following code, found on page 9 of the progam 
listing: 

create temp table pat eoc( 

patient char(15), 

relationship char(l), 

sex char(l)) in userspacel; 

declare ins pat eoc cursor for 

insert into pat eoc values (cpatient, crelationship, csex) 

open ins pat eoc 

The following program segment, found on page 6 of the pp comp.4sl program 
listing, deletes every record from the eoc table containing a patient, relationship and sex 
combination listed in the pat eoc table, thus removing all of the records for every 
patient who was considered as having complications for the stated medical condition: 

prepare del comp eoc from 

delete from eoc where e claim id = 

call errorlos C'updatins Comp Patients'') 

declare comp pat curs cursor for 

select unique e claim id 

from e claim cc, pat eoc pe 

where ccpatient = pe.patient and 

ccrelationship = pe,relationship and 

ccsex ~pe,sex 



foreach comp pat curs into c.e claim id 

execute del comp eoc using c.e claim id 
end foreach 
« • • 

call errorlog ("done with comp Patients") 
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Thus, at this step, all records for patients having a complication flagged in their 
medical claims history are deleted from the eoc table and removed from further 
consideration for episode or profile building. 
d) Qualify Episodes of Care For Profile Assignment 

At step 1670, each potential episode of care in the eoc table is checked against 
EOC quaUfying rules to determine whether the episode will be assigned to a profile. 
Episodes that fail the quahfying rules are not removed from the eoc table; but neither 
are they assigned a profile. Step 1670 is implemented in pertinent part by a foreach 
statement that loops through each record in the eoc table, which, as mentioned 
previously, now contains all claims line item records that have been found to be part of 
a valid episode of care. 

The following statements (including tiiQ foreach statement) appears in the 
pp comp.4gl program listing beginning on page 7: 

open qual ins 
let icount = 0 

foreach qeoc curs into cur eoc nam, q.date of serVj g.cpt, qJcdl 

let q. category = 

open set cat usin^ q.cpt 

fetch set cat into q.category 

if icount=0 then 

let prev eoc = cur eoc num 

end if 



if cur eoc num != prev eoc then 
close qual ins 



let eoc profile = " 

call qual'CheckC^E^') returning passed, eoc profile^ rule err 
execute upd eoc usins eoc profile, prev eoc 



open qual ins 

let prev eoc -cur eoc num 
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end if 

put qual ins 

end foreach 

Before invoking the foreach statement, the program begin by opening a 
temporary table, qual ins, that is used for storing a patient's records based on the 
results of the quahfication process (that is, the qual check function). Thereafter, the 
foreach loop is begun. In thQ foreach loop, an if/else conditional is used to determine 
whether the record being processed is the first patient record in the eoc table, and if so, 
initializes the prev eoc variable to the current EOC number. Thereafter, the 
qual check function is invoked with a value of "E" in the in scope variable, which 
indicates that episode qualifying rules are to be used by the function. 

As is set forth in detail in Section (d) above, the qual check function executes 
different logic based on the type of qualifying rules that are associated with the selected 
Index Code. For episode qualification, the same three sets of qualifying logic (Type II, 
Type IC, Type CC) are employed as in the patient qualification process, except that 
access to the quahfying tables (and rules) is determined by the scope value "E" rather 
than "P". Again, the qualifying rules are defined by the contents of the same set of four 
qualifying tables - the Qualifying Master, Qualifying Group, Qualifying Index, and 
Qualifying Code tables. For episodes of care, however, the qualifying rules determine if 
a potential EOC meets the minimum profiling criteria expected for the selected Index 
Code (e.g., episode includes procedure codes indicating surgical services required for 
the medical condition). 

As compared with its operafion in the patient qualification process set forth 

above, when executed for episode qualification, the qual check function evaluates 

whether the qualifying logic only until the first set of rules are "passed." If any rule is 

considered "passed," then the episode currently being processed has qualified for 

profiling. The qual check function discontinues episode qualification and returns 

control back to the pp contp.4sl program. In addition to the rule passed value, the 

qual check function returns to the main program a value in the eoc profile variable, 

which profile number {profile num) is then inserted into the eoc table. The qual check 
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function sets the value of eoc profile to equal the contents of the Profile field of the 
Qualifying Master table {qm.profile). If the episode of care does not satisfy the 
qualifying criteria, the eoc profile variable the episode is not assigned a profile. Thus, 
the qual check function not only determines whether the episode may profiled but also 
to which profile it belongs. 

The profiles assigned to episodes correspond to combinations of treatment 
patterns that are likely to arise for a given medical condition. There are eight basic 
profile classes to which an episode of care may be assigned. The profile classes identify 
common combinations of treatment pattems that are useful for statistically analyzing 
and reporting on medical provider billing data. These Profile Classes are: 

0. Common Profile (diagnostic and E/M services common to all of the 

above). 

1 . Surgery/Medicine/Radiation Profile 

2. Medicine/Radiation Profile 

3 . Surgery/Radiation Profile 

4. Surgery/Medicine Profile 

5. Radiation Profile 

6. Medicine Profile 



7. Surgery Profile 

e) Append Category Information to the EOCs 

After all vahd EOCs have been assigned to a profile, processing continues at 
step 1680 with appending category data to the eoc table records. Specifically, at step 
1680, all of the CPT codes in the eoc table records are categorized using the cat file 
table created at step 1645. This step involves the re-categorization of all CPT codes but 
only in the patient records that have been qualified for episode of care creation during 
the previous program step 1670. The functionality is similar to that in step 1670; the 
difference being that in step 1680, the category code is appended to the eoc table record, 
whereas in step 1670, the category code is held temporarily in a variable to assist in the 
EOC profile categorization. (During execution of th^ foreach loop of step 1670, the 
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program performs a lookup on the category table based on the procedure code of the 
medical record in question to assist in the profile categorization of an episode.) In an 
alternative embodiment, not implemented in the Microfiche Appendix, the eoc table 
with category information appended is then used to populate the procedure and category 
parameter tables, which store historical billing and statistical information by Index 
Code. 

f) Populate the Procedure and Category Parameter Tables 

In the above-referenced alternative embodiment, at step 1685, data from 
qualified eoc table records (that now include category codes) is added to the procedure 
and category parameter tables. In general, data firom all of the episodes of care for each 
Index Code are inserted into parameter tables to allow for summary statistical profiling. 

g) Generate Output 

In yet another embodiment, statistical profiles and other analysis of the data fi-om all 
episodes of care are provided through the generation of output reports, 1690. The 
output reports may be implemented as an online table look-up or a hard copy report. 

It is to be understood that the above-described embodiments are merely 
illustrative of numerous and varied other embodiments which may constitute 
applications of the principles of the invention. Such other embodiments may be readily 
devised by those skilled in the art without departing fi-om the spirit or scope of this 
invention and it is our intent that they be deemed within the scope of our invention. 
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